PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/Delphi Digests/Delphi Vol. 2/Delphi 2.15

Text File | 1986-04-18 | 25.7 KB | 639 lines | [TEXT/ttxt]

ret
 1 message retrieved.

 Message: 1254964, 610 lines
 Posted: 10:25pm EST, Thu Apr 17/86, imported: 10:38am EST, Fri Apr 18/86
 Subject: Delphi Mac Digest V2 #15
 To: Peter_Johnston@UQV-MTS, MacTechnics User Group, Gavin Eadie, Abraham
     Vanderspek
 From: [e-mail]

 Delphi Mac Digest          Friday, 18 Apr 1986      Volume 2 : Issue 15

 Today's Topics:
      MacWrite & new ROMS
      Re: DiskBench
      Re:  DiskBench (Re: Msg 7316)
       DISK DRIVE
      Re: Bad Mount Bug in New ROMs
      RE: Hot rumor (Re: Msg 7278)
      Re: another survey
      Lightspeed C and New Traps
      RE: Lightspeed C and New Traps (Re: Msg 7334)
      VAX host software for Mac
      RE: INFO-MAC Digest V4 #56 (Re: Msg 7345)
      Drive queue
      RE: Drive queue (Re: Msg 7366)
      Re: 128K ROM version number
      Re: 128K ROM version number
      Reply to "The art of benchmarks"
      RE: Reply to "The art of benchmarks" (Re: Msg 7386)
      RE: Reply to "The art of benchmarks" (Re: Msg 7386)
      RE: Reply to "The art of benchmarks" (Re: Msg 7391)
      Reply to "The art of benchmarks"
 ----------------------------------------------------------------------

 From: JEFFS (7301)
 Subject: MacWrite & new ROMS
 Date: 13-APR 19:37 Bugs & Features

 Ever since my upgrade to the new ROMS, MacWrite keeps bombing about
 once an hour or sometimes not for several.  Anyone else have these
 problems?  It happens randomly with both RAM cache disabled and
 enabled.
                                                Jeff

 ------------------------------

 From: BRECHER (7316)
 Subject: Re: DiskBench
 Date: 14-APR 06:45 MUGS Online

 To: [e-mail] (pri=8 Ephraim Vishniac x76659 ms1459)

 The enthusiasm with which DiskBench has been received is due to the
 fact that it's the only game in town.  Previously, the only timely
 "information" on hard disk performance was advertising hype and
 reports from users that such-and-such a disk is "very fast," or
 subjective comparitive reports where influential extraneous factors
 (such as the file system in use) were not held constant.  I wrote
 DiskBench in the afternoon preceding a local MUG meeting at which a
 vendor demoed his hard disk product.  I have never claimed that
 DiskBench is "realistic" in the sense of emulating I/O patterns
 generated by typical user activity.  It merely provides *some*
 indication of performance of the hardware and hardware-related
 software.

 "Unheard of" may be too strong -- there are large code segments and
 large documents.  Regardless, as to emulating typical I/O patterns, I
 think the best way to do that would be to instrument a disk driver, or
 install a patch to _Read/_Write, to record the locations/extents of
 requests during some sequence of "typical" user activity -- such as
 launching documents and quitting from several heavily-used
 applications -- and then using the resulting activity database to
 direct a "raw I/O" benchmark program.  This approach, although much
 more realistic than DiskBench's, is flawed by the problem of different
 drive geometries causing a different frequency of cylinder-crossing
 for a given set of logical I/O requests.  If the set were large
 enough, though, that problem might not be significant.

 As to the unknown rotational latency bias, your point is well taken.
 Courtesy of Jeff Shulman, I have your modified DiskBench source
 (version 3.0) which incorporates your "dithering" scheme.  One problem
 with the implementation is that it applies the 60Hz timer granularity
 to each I/O rather than to the test as a whole.  With the faster
 drives, there is a chance of significant cumulative timing error.  A
 simple solution would be to use a constant ordered set of "dither"
 delays rather than generating a new random set on each run; a dry run
 pass without I/O could be used to measure the total delay and subtract
 it out of the total test time.  A constant set could be obtained
 without actually incorporating the data into the program merely by
 seeding QuickDraw's random variable with a constant.

 I encourage you, or anyone improving DiskBench, to modify the name of
 the program as distributed (e.g., "DiskBench3") and to modify the
 results dialog to include the new name.  It will get confusing at best
 if people start unknowingly comparing results from two different
 programs.

 More generally, I would like to see some disinterested party -- e.g.,
 a non- advertising publication such as MacInTouch, or a user group --
 undertake construction of a really good hard-disk benchmark, run it on
 *several* specimens of each drive (to eliminate outliers due to bad
 sectors/tracks in the set comprising the test) and maintain and
 publish the results.  Before such a program is used its source code
 might be submitted to the community for comment and criticism.

 ------------------------------

 From: RICFORD (7322)
 Subject: Re:  DiskBench (Re: Msg 7316)
 Date: 14-APR 09:51 MUGS Online

 My current plan for MacInTouch benchmarks is to establish a new set of tests
 based on a 1M-byte Mac Plus with the EA-checksum ROMs, System 3.2, Finder 5.3,
 etc.  We'll do basically the same thing we did before, but may add things to
 test graphics performance, performance with larger files, and a numerics test
 with something which uses SANE (not Excel).

 We have already done some tests comparing HFS to MFS (MacBottom) and
 Finder 5.0 to Finder 4.1 (HyperDrive).  Our intent is to solidify
 these comparisons between "generations" when Apple gets stable system
 software out, and to then standardize on the new generation of
 software for testing.

 We'd certainly like to test multiple samples of hard drives from vendors, but
-I
 expect that it will be a problem getting them, unless there is a major outcry
 from users/consumers.  We're not quite the "Consumer Reports" of the Mac World
 -- we don't have a hardware budget big enough to purchase a number of units of
 each drive.

 It's true, though, that performance, and things like noise and reliability are
 hard to judge from a single sample.  The best information is an informed
 consensus that develops over time, and I had hoped other people would do the
 MacInTouch benchmarks, too.  They haven't -- probably because it's too much
 work.  DiskBench is sure a lot easier to run. I think we need to develop
 something in between the two, if we don't establish a complete, funded testing
 organization.

 Ric Ford

 "MacInTouch" newsletter

 ------------------------------

 From: JIMSB (7310)
 Subject:  DISK DRIVE
 Date: 14-APR 00:23 Hardware & Peripherals

 Can any one recommend a good disk drive diagnostic program ?

 Thanks,

 Jim

 ------------------------------

 From: BRECHER (7317)
 Subject: Re: Bad Mount Bug in New ROMs
 Date: 14-APR 06:47 MUGS Online

 To: Roy Leban <[e-mail]>

 The disk mounting logic knows nothing of the Desktop file.  On my
 system (128K ROMs, no Aztec), lack of a Desktop file is no bar to
 mounting when Finder is not running.  There must be some other cause
 of your problem.  With a debugger, you could trap _Mount and see what
 result it's returning.  The problem could be related to the system
 heap configuration when Shell is running.

 ------------------------------

 From: RICFORD (7325)
 Subject: RE: Hot rumor (Re: Msg 7278)
 Date: 14-APR 14:27 Macintosh In Fact

 Mac 512K Enhanced 4/14/86

 Apple announced today the Mac 512K Enhanced for $1999.  This
 replacement for the Mac 512K includes the 128K ROMs that are in the
 Mac Plus, and the 800K internal disk drive.  Instead of MacWrite and
 MacPaint, Apple now encloses a disk with _sample_ versions of
 MacWrite, MacPaint, MacProject, Mac Pascal, and Mac Draw. Also
 included is a tools disk for upgrading disks with older systems.
 Availability is real soon now... oops, I mean late April.

 Ric Ford

 "MacInTouch" newsletter

 ------------------------------

 From: RICFORD (7342)
 Subject: Re: another survey
 Date: 15-APR 08:53 MUGS Online

 In reply to Rocko at: [e-mail]

 The latest versions we know of are: MacTerminal 2.0, Red Ryder 8.0 (has some
 bugs, but works better on Mac Plus), FEdit 3.5, ResEdit 1.0D7, MacTools/Copy
-II
 5.1 (supports 800K drives), Switcher 4.9 (not quite released), MacDraw 1.9,
 System 3.1.1 and Finder 5.2  (new System/Finder/Chooser/print drivers in May?)

 Ric Ford

 "MacInTouch"

 ------------------------------

 From: DWB (7334)
 Subject: Lightspeed C and New Traps
 Date: 14-APR 22:59 Programming

 Just got off the phone with the folks at THINK.  I was complaining
 about the lack of support for the traps in the new roms and they
 provided the following assistance.  If you declare a routine:

 pascal short NewTrap() = 0xa835;

 You declare a new inline call NewTrap which returns a short and is $a835.
-Note
 two things.  First, this will only work for stack based traps.  Second, the
-hex
 number can be anything, it doesn't have to be a trap.  Well, actually it can
-be
 any word.  You could, however, if you really wanted to say:

 pascal void RTE() = 0x4e73;

 int_routine()
 {
         ...
         RTE();
 }

 and insert an inline RTE instruction.

 Given this information, I have updated the NewRom stuff located in the Public
 Domain section to take advantage of this fact.

 David

 ------------------------------

 From: DWB (7337)
 Subject: RE: Lightspeed C and New Traps (Re: Msg 7334)
 Date: 14-APR 23:26 Programming

 Oh yeah, another neat and hidden feature.  When you use RelConv to turn an MDS
 .rel into a Lightspeed .lib file it creates a .voc file.  If you edit that
-file
 you can change the capitalization of routine names.  Basic process looks like:

 Edit .asm
 Assemble .asm
 RelConv .rel
 Edit .voc
 RelConv .rel

 You now have a .lib with multi-case names.  You could also create the
 .voc file before running RelConv the first time.  Any symbols not in
 the .voc file will be added to it.

 Ain't it wunnerful the things they don't tell you.  Especially when they're
 useful things.

 David

 ------------------------------

 From: RICFORD (7346)
 Subject: VAX host software for Mac
 Date: 15-APR 12:55 Business Mac

 Pacer Software, Inc. is supposedly now shipping host software for VAX
 systems running either VMS or Ultrix that supports terminal emulation,
 print spooling, and file transfer between Macintoshes.  MacBinary file
 transfer is supported now, and so is the high-speed Omninet hardware.
 (RS232 is the normal means of connection).  Future plans include file
 server support, which they now suppy for IBM/PCs, and VT240 emulation
 (currently VT100, VT220 and third-party emulation).

 pcLINK requires a Mac 512K or Mac Plus and costs $2000 for a host license that
 provides for up to 5 Mac's operating concurrently.  The Mac software itself is
 not copy-protected.  A command language for the VAX host software permits
 batched file transfers, and the VAX can initiate transfers to the Mac.

 The main office is at 1227 Pearl St., La Jolla, CA  92037. 619-454-0565 The
-R&D
 office is at 100 Pennsylvania Ave., Suite 320, Framingham, MA 01701.
 617-879-1765.

 I have no affiliation with Pacer Software and I have not seen the system in
 action, but I thought it sounded interesting.

 Ric Ford

 "MacInTouch" newsletter

 ------------------------------

 From: MOUSEKETEER (7351)
 Subject: RE: INFO-MAC Digest V4 #56 (Re: Msg 7345)
 Date: 15-APR 21:56 MUGS Online

 One more to add to the current version list:  Thunderscan software is
-presently
 at version 3.2.

 ------------------------------

 From: JIMH (7366)
 Subject: Drive queue
 Date: 16-APR 23:05 Programming

 INside mac says that the drive queue contains elements that have 4
 status and flag bytes followed by pointer to the next item,
 qtype,drive number, ect.  however my globals list says the header is
 at $308 and it does not seem to be a valid queue entry as it is 10
 bytes long which is to short.  it also points to a linked list of
 entrys which have only 2 bytes befor the pointer. in this months
 mactutor there is an excellent article on a nested volume manager in
 C, and i am just hacking aroun d with my debugger looking at this
 queue.  could anyone tell me why it does not look like the queue in
 the documentation?  Also the article talks about a byte which when set
 to 8 will make the drive no ejectable. does this also include dragging
 it to the trash can? my tecmar will let me eject the hard disk, what i
 really want to know is if i set this byte to 8 will that stop the
 tecmar from being ejected?  thanks jim

 ------------------------------

 From: DWB (7380)
 Subject: RE: Drive queue (Re: Msg 7366)
 Date: 17-APR 01:53 Programming

 What is located at $308 is a "Drive Queue Header".  What it contains
 is a 2-byte flag word, a 4-byte pointer to the head of the queue and a
 4-byte pointer to the end of the queue.  If you find the Drive entry
 corresponding to the TecMar by following the queue and then change the
 byte at offset -3 from the entry and change it to 8 the drive will be
 non-ejectable.  This doesn't prevent it from being drug into the
 trashcan I don't believe.  The reason you have to use index -3 is
 because the flags aren't a proper part of the mac's generic queue
 structure.  Some queues have them some don't. Thus some genious
 decided that the link entries would point to the next link entry and
 the flag words would be before that.  To clarify $30A: $1000 ; this is
 the first drive in the queue $30E: $2000 ; this is the last drive in
 the queue

 $FFC:   driveflags      ; flags word
 $1000:  $2000           ; link to next drive

 $1FFC:  drive2Flags     ; flags for drive 2
 $2000:  0               ; null link is end of queue

 Hopefully this will clear things up

 David

 ------------------------------

 From: RICFORD (7390)
 Subject: Re: 128K ROM version number
 Date: 17-APR 13:43 MUGS Online

 I don't want to belabor this, and I thank Darin Adler for his helpful
 information on PTCH resources and ROM versions, but I think he meant
 $0075 and 117(dec.) for the 128K ROM version number, not $0076.  We
 did find $0075 in both EE-checksum and EA-checksum ROMs.

 (aside: it's good to see Darin on the net.  We are very fond of
 SkipFinder, although the latest version we have exits to the Finder
 when one attempts to use the open document option)

 Ric Ford

 "MacInTouch"

 ------------------------------

 From: PEABO (7392)
 Subject: Re: 128K ROM version number
 Date: 17-APR 14:45 MUGS Online

 Re:  "exit to Finder when one attempts to use the open document option"

 Well, the Finder *does* open documents, does it not?

 ;-)

 ------------------------------

 From: BRECHER (7386)
 Subject: Reply to "The art of benchmarks"
 Date: 17-APR 07:40 MUGS Online

 To: [e-mail] (John Bass)
 Subject: Reply to "The art of benchmarks"
 From:  Steve Brecher

 Background: DiskBench was written during an afternoon prior to a
 user's group meeting at which Steve Edelman of SuperMac was appearing
 with his DataFrame product.  DataFrame was getting a reputation as a
 relatively fast, well-designed and well-supported product (deserved,
 as far as I can tell).  I had spoken with Edelman at the January Expo
 and he was, at that time, the *only* person I had spoken with who had
 some understanding of the problems in Apple's SCSI Manager
 implementation.  I took DiskBench to the meeting to get some
 indication of DataFrame's performance.  DiskBench was intended to
 provide, and does provide some indication of data transfer speed and
 access speed.  I have never claimed it to be a realistic benchmark in
 the sense of measuring typical I/O patterns.

 Since DiskBench was the only objective (if quite imperfect) measure of
 performance extant among a sea of ad claims and user impressions, I
 published it (on nets, source included) and invited hard disk owners
 to submit results.  One of the results submitted was for the Warp 20,
 indicating a 32KB data transfer speed an order of magnitude slower
 than other SCSI or internal subsystems.  I questioned the submittor of
 those results, under the assumption that they were invalid for some
 reason. Pursuant to my skepticism, he repeated the test with the same
 results. Later, a virtually identical result for the Mirror MagNet
 seemed confirmative, as I had heard that Mirror and Warp 9 were
 closely-related companies.

 I can't follow the timing arguments (thus I opt for stupidity rather than
 dishonesty, which are the alternatives provided me in Bass's message):

 > I know of NO SASI/SCSI controller that will read a sector in LESS than
 > 4ms from select to status complete if the data is just about under the
 > heads.

 A sector takes less than 0.9ms to pass under the head.  Overhead for header
 processing, ECC calculation, status, etc., does not quadruple the time.  If it
 took at least 4ms per sector, how could SCSI controller manufacturers
-advertise
 (and provide) 1:1 interleave capability?

 > Even if Micah's hostadapter is fully hardware DMA ...
 > ...
 >       1: the 1:1 interleave he claims can only be had by turning off
 >          interrupts -- this will certainly cause performance problems
 >          ...
 >          At 1:1 ANY mouse, printer, or clock interrupts WILL cause
 >          the interleave to be lost resulting in about a 18.6ms rotational
 >          delay.

 MicahDrive does not use DMA nor turn off interrupts.  It uses programmed I/O
 with an NCR 5380-based host adapter (same as in Mac Plus and MacSCSI).

 I just performed DiskBench on MicahDrive whilst continuously moving the mouse
 around in about a 4-inch circle approx. 2 rev/sec.  The results (along with
-the
 originally-reported results):

                                Data transfer  Access
                               ---- time ----   time  (all figures are ticks)
                               Reads   Writes

  continuous mouse movement      794      814    499
  original (no mouse movement)   508      507    488

 The total reported time is accurate to within a second as verified by
 the second hand of a wristwatch (i.e., time is not understated due to
 loss of VBL interrupts).  If, as Bass claims, it took 18+ms for each
 sector, due to inevitable missed sectors, the data transfer times
 would be an order of magnitude higher.  Perhaps Bass assumes a
 controller that has no buffering; Micah's has a buffer.

 > The Micah host adapter is not MacPlus compatable -- where will you have to
-go

 > to get a second drive or tape when you upgrade with Micah??? --- only Micah.

 Huh?  The MicahDrive will install in either a 512K or Mac Plus, and is
 currently running in both, in customer machines.  If you want a second
 drive or tape on a Plus, you plug it into the SCSI port on the back
 (or if it's a serial or floppy-port drive, into those ports).  The
 MicahDrive host adapter and the Plus built-in (motherboard) host
 adapter are entirely separate and non-interfering.

 > If there is really a warped need to go faster I can supply a
-drive/controller
 > and host adapter that is MacPlus compatable that is a full 7.5mb/sec ...
 > (that is 50% faster than Micah) -- not cheap (about $1600) ...

 (Nice pun.)  While admittedly without marketing expertise, I think
 that speed is important to hard disk buyers.  Since MicahDrive and
 HyperDrive currently list for more than $1600, I feel you would do
 very well with such a product.  Programmed byte-wide I/O executing
 from ROM, stock Mac 8MHz CPU, is limited to about 5.3 Mbit/sec (0.67
 Mbyte/sec) [12 clock cycles for Move.B (An),(An)+].  Thus I guess
 you'd need either a word-wide interface, or DMA (which my hardware
 friends tell me is hard to do on a Mac); if you've got the design, go
 for it.

 > Micah's cheap shot at Mirror with this shoddy benchmark ...

 DiskBench was written and published without the knowledge of Micah, Inc., nor
 any of their personnel.  (I wrote the MicahDrive system software under
-contract
 to Micah.)  As to the idea that it's a "shot at Mirror" -- I'm at a loss.

 > They [Micah] bought one of my units very early on and drove down here and
 > wasted a half day of my time to help them get it going with their drive.

 This was before my association with Micah.  When they called me, they were
 watching their system decay to death fairly rapidly due to utter lack of I/O
 error checking in Bass's formatter and driver.  The current Micah hardware and
 software bear no resemblance, as progeny or otherwise, to the MacSCSI
-products.

 > My background and qualifications include nearly 15 years of systems
 > programming and performance tuning on IBM, DEC, UNIX and a dozen other
 > mini/micro systems.

 Yeah, I'm getting old too.  Don't remind me.  About ten disk drivers, firmware
 for four or so disk controllers, and far too few wanton women.

 DISCLAIMER:  I don't have to disclaim anything, because I'm writing this on
              Delphi.  Nyah, nyah.

 APHORISM:    Nostalgia ain't what it used to be.

 COMPLICATED NETWORK ADDRESS:    Jeff Shulman takes care of that for us
                                 (thanks, Jeff).


 ------------------------------

 From: RICFORD (7389)
 Subject: RE: Reply to "The art of benchmarks" (Re: Msg 7386)
 Date: 17-APR 10:57 MUGS Online

 We gonna have to start giving out Purple Hearts for flame burns around here...

 :-)

 ------------------------------

 From: PEABO (7391)
 Subject: RE: Reply to "The art of benchmarks" (Re: Msg 7386)
 Date: 17-APR 14:43 MUGS Online

 A sense of humor is a valuable asset in an otherwise complicated world.

 (I guess that's my aphorism.)

 peter

 ------------------------------

 From: FRIED (7395)
 Subject: RE: Reply to "The art of benchmarks" (Re: Msg 7391)
 Date: 17-APR 19:24 MUGS Online

 Just don't count on getting rich selling it. <grin>

 ------------------------------

 From: RWIGGINS (7397)
 Subject: Reply to "The art of benchmarks"
 Date: 17-APR 20:23 MUGS Online

 To: [e-mail] (John Bass)
 Subject: Reply to "The art of benchmarks"
 From:  Robert R. Wiggins

 I feel compelled to respond to this unprofessional attack against a
 fellow professional.  I also have 15 years of experience in this
 business, including 5 working for IBM.  If an IBM employee made the
 same kind of negative remarks about a competitor in public, he or she
 would be fired, whether or not the remarks were accurate.  IBM knows
 that such remarks only serve to detract from the reputation of the
 speaker.  As a consumer, I agree, and find your remarks to say more
 about you than they do about Steve Brecher or Micah.

 Mr. Brecher has already responded to your technical arguments, but I would
-like
 to add some comments of my own.  I am not in any way associated with Micah,
-and
 in fact derive my primary income from mainframes, not micros.

 > I did a study of disk requests to the driver last summer on my 5mb drive,
 > nearly all were less than a few sectors.

 "Less than a few" is a remarkable number for a study to turn up.

 > To wrap this up -- Micah's cheap shot at Mirror with this shoddy benchmark
 > is only to try and buy market share after they have been advertising
 > vaporware for months.

 Again, the fact that you view this benchmark as a "shot" says more
 about you than it does about anyone else.  Micah did not write this
 benchmark, nor distribute it, nor (as far as I know) have they made
 any use of the results.  Steve Brecher did write the software for the
 Micah on a contract basis, but this hardly makes him an agent for
 Micah in all his future endeavors.

 > In this case I think that the lack of understanding that Mr Brecher seems to
 > have in the total system timings may reflect other short comings in the
 > quality of the product he is pushing. More over IF HE REALLY DOES UNDERSTAND
 > THESE TIMINGS AND WITHHELD THEM then he is very guilty of presenting a
 > falsehood on the market place.  In either case it leaves a lot of
 > questions in my mind about both Mr. Brecher and Micah.

 This is truly insulting to Mr. Brecher.  Not only do you question his
 competence, but also impute base motives to him.  I will agree (and
 Mr. Brecher might also) that his benchmark is not the be-all and
 end-all when it comes to disk performance.  It is merely an attempt to
 measure two variables of disk speed in a consistent manner across many
 different types of disk in an industry where virtually no one
 publishes geometry specifications.  Andy Hertzfeld and Steve Brecher
 had a dialog in public about this benchmark, with Andy on the side of
 access time (which the benchmark does include) as the more important
 variable.  After a spirited discussion, Andy agreed that the benchmark
 was one way to get an idea of relative disk performance, but not the
 only way. I am a large systems performance specialist, and for the
 DASD I work with data transfer is a small component of total service
 time (of course, these service times are usually less that 20 ms), so
 I would tend to agree with Andy.  But I think that Mr. Brecher has
 done the Mac community a service in providing a means, however
 simplistic, of comparing disk drive performance.  And I think you do
 yourself and your company a disservice by promulgating innuendo about
 a well-known and well-respected professional.

 -- Robert R. Wiggins

 ------------------------------

 End of Delphi Mac Digest
 ************************

 -------

 Next, history, delete, reply, help, etc.?
@